25 tháng 9, 2025Tiếng Việt

Khám phá Registry Runtime của Module Federation JavaScript để khám phá module động, cho phép kiến trúc microfrontend có khả năng mở rộng và thích ứng. Tìm hiểu về triển khai, lợi ích và các trường hợp sử dụng nâng cao.

Registry Runtime của JavaScript Module Federation: Khám phá Module Động

Module Federation, một tính năng mạnh mẽ được giới thiệu bởi Webpack 5, đã cách mạng hóa cách chúng ta xây dựng và triển khai các ứng dụng JavaScript, đặc biệt là trong lĩnh vực microfrontends. Nó cho phép các ứng dụng khác nhau, được xây dựng và triển khai độc lập, chia sẻ mã và chức năng tại thời điểm chạy. Mặc dù các cấu hình Module Federation tĩnh phổ biến, sức mạnh thực sự nằm ở khám phá module động bằng cách sử dụng Registry Runtime. Bài viết này đi sâu vào khái niệm Registry Runtime cho Module Federation, khám phá cách triển khai, lợi ích và các trường hợp sử dụng nâng cao.

Registry Runtime là gì?

Trong bối cảnh Module Federation, Registry Runtime đóng vai trò là một thư mục hoặc dịch vụ trung tâm cung cấp thông tin về các module từ xa có sẵn. Thay vì mã hóa cứng vị trí của các module từ xa trong cấu hình ứng dụng của bạn, bạn truy vấn registry tại thời điểm chạy để khám phá và tải các module cần thiết. Phương pháp động này mang lại nhiều lợi ích:

Tách biệt: Các ứng dụng ít phụ thuộc chặt chẽ vào các phiên bản hoặc vị trí cụ thể của các module từ xa.
Khả năng mở rộng: Dễ dàng thêm, xóa hoặc cập nhật các module từ xa mà không cần triển khai lại các ứng dụng tiêu thụ.
Khả năng thích ứng: Cho phép bật/tắt tính năng động và thử nghiệm A/B bằng cách phục vụ các module khác nhau dựa trên các điều kiện thời gian chạy.
Khả năng phục hồi: Nếu một module từ xa không khả dụng, registry có thể cung cấp một vị trí hoặc phiên bản thay thế.

Tại sao sử dụng Registry Runtime?

Hãy xem xét một nền tảng thương mại điện tử lớn bao gồm nhiều microfrontends, chẳng hạn như danh mục sản phẩm, giỏ hàng và tài khoản người dùng. Mỗi microfrontend được phát triển và triển khai độc lập. Nếu không có Registry Runtime, mỗi microfrontend sẽ cần biết chính xác vị trí và phiên bản của bất kỳ module hoặc thành phần dùng chung nào được sử dụng bởi các microfrontends khác. Điều này tạo ra sự phụ thuộc chặt chẽ và gây khó khăn cho việc cập nhật. Ví dụ, việc cập nhật một thành phần UI dùng chung sẽ yêu cầu triển khai lại tất cả các microfrontends phụ thuộc vào nó.

Tuy nhiên, với Registry Runtime, các microfrontends chỉ cần truy vấn registry để biết vị trí và phiên bản của thành phần cần thiết. Registry sau đó có thể cung cấp thông tin phù hợp, cho phép các microfrontends tải thành phần một cách động. Sự tách biệt này cho phép cập nhật độc lập và giảm rủi ro thay đổi gây lỗi.

Triển khai Registry Runtime

Có nhiều cách để triển khai Registry Runtime, từ các tệp JSON đơn giản đến các dịch vụ phức tạp hơn với khả năng quản lý phiên bản và định tuyến. Dưới đây là một ví dụ cơ bản sử dụng tệp JSON đơn giản được lưu trữ trên máy chủ web:

1. Định nghĩa Registry (registry.json):


{
  "modules": {
    "@my-org/product-card": {
      "1.0.0": "https://cdn.example.com/product-card/1.0.0/remoteEntry.js",
      "1.1.0": "https://cdn.example.com/product-card/1.1.0/remoteEntry.js"
    },
    "@my-org/checkout-button": {
      "2.0.0": "https://cdn.example.com/checkout-button/2.0.0/remoteEntry.js"
    }
  }
}

Tệp JSON này định nghĩa các module có sẵn và URL tương ứng của chúng. Mỗi module có các mục được phiên bản trỏ đến các tệp `remoteEntry.js` tương ứng. Điều này cho phép quản lý phiên bản và dễ dàng quay lại nếu cần.

2. Ứng dụng tiêu thụ:


async function loadRemote(moduleName, version) {
  const registryUrl = 'https://example.com/registry.json';
  const response = await fetch(registryUrl);
  const registry = await response.json();

  const moduleInfo = registry.modules[moduleName];
  if (!moduleInfo) {
    throw new Error(`Module "${moduleName}" not found in registry.`);
  }

  const moduleUrl = moduleInfo[version];
  if (!moduleUrl) {
    throw new Error(`Version "${version}" for module "${moduleName}" not found.`);
  }

  return new Promise((resolve, reject) => {
    const script = document.createElement('script');
    script.src = moduleUrl;
    script.type = 'text/javascript';
    script.async = true;
    script.onload = () => {
      // Module is loaded, you can now access it using window[moduleName]
      resolve(window[moduleName]);
    };
    script.onerror = (error) => {
      console.error(`Error loading module ${moduleName} from ${moduleUrl}:`, error);
      reject(error);
    };
    document.head.appendChild(script);
  });
}

// Example usage:
loadRemote('@my-org/product-card', '1.0.0')
  .then((module) => {
    // Use the loaded module
    const ProductCard = module.ProductCard;
    const productCardInstance = new ProductCard({ name: 'Example Product' });
    document.getElementById('product-card-container').appendChild(productCardInstance.render());
  })
  .catch((error) => {
    console.error('Failed to load product card:', error);
  });

Đoạn mã này minh họa cách truy xuất registry, xác định vị trí module và phiên bản mong muốn, đồng thời tải động entry từ xa. Nó cũng bao gồm xử lý lỗi cơ bản.

3. Cấu hình Webpack (ứng dụng từ xa):


const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  //...
  plugins: [
    new ModuleFederationPlugin({
      name: '@my-org/product-card',
      filename: 'remoteEntry.js',
      exposes: {
        './ProductCard': './src/ProductCard',
      },
      // shared: { ... }, // Shared dependencies
    }),
  ],
};

Đây là cấu hình Webpack Module Federation tiêu chuẩn cho ứng dụng từ xa, hiển thị thành phần `ProductCard`. Điểm mấu chốt ở đây là `filename` là `remoteEntry.js`, đây là tệp được tham chiếu trong registry.

Các Trường hợp Sử dụng Nâng cao

Ví dụ đơn giản trên có thể được mở rộng để xử lý các tình huống phức tạp hơn:

Quản lý Phiên bản

Registry có thể lưu trữ nhiều phiên bản của mỗi module, cho phép các ứng dụng tiêu thụ chỉ định phiên bản mong muốn. Điều này rất quan trọng để duy trì khả năng tương thích và cho phép nâng cấp dần dần.

Ví dụ: Registry có thể chứa thông tin phiên bản và ứng dụng tiêu thụ có thể yêu cầu một phiên bản cụ thể hoặc một phạm vi phiên bản chấp nhận được (ví dụ: '>=1.0.0 <2.0.0'). Sau đó, registry có thể trả về URL phù hợp dựa trên yêu cầu.

Định tuyến và Cân bằng Tải

Registry có thể hoạt động như một bộ cân bằng tải, chuyển hướng các yêu cầu đến các máy chủ khác nhau dựa trên tính khả dụng hoặc vị trí địa lý. Điều này có thể cải thiện hiệu suất và độ tin cậy.

Ví dụ: Registry có thể có nhiều URL cho cùng một module, mỗi URL trỏ đến một CDN hoặc máy chủ khác nhau. Sau đó, registry có thể sử dụng thuật toán cân bằng tải để phân phối các yêu cầu trên các máy chủ có sẵn.

Xác thực và Ủy quyền

Registry có thể thực thi các chính sách xác thực và ủy quyền, đảm bảo rằng chỉ các ứng dụng được ủy quyền mới có thể truy cập các module cụ thể. Điều này là cần thiết để bảo mật mã và dữ liệu nhạy cảm.

Ví dụ: Registry có thể yêu cầu khóa API hoặc token để truy cập thông tin module. Ứng dụng tiêu thụ sẽ cần cung cấp thông tin đăng nhập chính xác để lấy URL module.

Bật/Tắt Tính năng

Registry có thể được sử dụng để triển khai các tính năng bật/tắt, cho phép bạn bật hoặc tắt các tính năng một cách động mà không cần triển khai lại ứng dụng. Điều này hữu ích cho việc thử nghiệm A/B và triển khai dần các tính năng mới.

Ví dụ: Registry có thể có các cấu hình khác nhau cho các môi trường hoặc nhóm người dùng khác nhau. Dựa trên danh tính của người dùng hoặc môi trường, registry có thể trả về các URL khác nhau cho cùng một module, hiệu quả là bật hoặc tắt các tính năng nhất định.

Kết hợp Module Động

Registry có thể tạo điều kiện thuận lợi cho việc kết hợp module động, nơi các module được tải tại thời điểm chạy phụ thuộc vào các điều kiện thời gian chạy hoặc tương tác của người dùng. Điều này cho phép các ứng dụng có khả năng thích ứng và cá nhân hóa cao.

Ví dụ: Dựa trên sở thích của người dùng hoặc ngữ cảnh của trang hiện tại, ứng dụng có thể truy vấn registry để tìm các module phù hợp để tải. Điều này cho phép trải nghiệm người dùng được tùy chỉnh cao.

Lưu ý và Thực tiễn Tốt nhất

Mặc dù Registry Runtime mang lại những lợi ích đáng kể, nhưng điều cần thiết là phải xem xét các yếu tố sau:

Hiệu suất: Truy xuất thông tin registry thêm một yêu cầu mạng. Cân nhắc bộ nhớ đệm dữ liệu registry để giảm thiểu độ trễ.
Độ phức tạp: Triển khai và bảo trì Registry Runtime làm tăng thêm độ phức tạp cho kiến trúc của bạn. Đánh giá cẩn thận sự đánh đổi trước khi áp dụng phương pháp này.
Bảo mật: Bảo vệ registry khỏi truy cập và sửa đổi trái phép. Thực hiện các cơ chế xác thực và ủy quyền phù hợp.
Xử lý Lỗi: Thực hiện xử lý lỗi mạnh mẽ để xử lý một cách êm đẹp các trường hợp registry không khả dụng hoặc module không thể tải được.
Khả năng mở rộng: Đảm bảo registry có thể xử lý tải dự kiến và mở rộng khi ứng dụng của bạn phát triển. Cân nhắc sử dụng cơ sở dữ liệu phân tán hoặc lớp bộ nhớ đệm để cải thiện hiệu suất.
Quản lý Tập trung: Thực hiện các quy trình quản trị và quản lý thay đổi phù hợp xung quanh registry để đảm bảo tính nhất quán và tránh xung đột.
Giám sát: Giám sát hiệu suất và tính khả dụng của registry để xác định và giải quyết các sự cố một cách chủ động.

Các Giải pháp Thay thế cho Registry JSON Đơn giản

Mặc dù tệp JSON đơn giản đóng vai trò là điểm khởi đầu tốt, các giải pháp mạnh mẽ hơn thường cần thiết cho môi trường sản xuất. Hãy xem xét các giải pháp thay thế sau:

Dịch vụ API Tùy chỉnh: Một dịch vụ API chuyên dụng được xây dựng bằng Node.js, Python hoặc Go cung cấp tính linh hoạt và kiểm soát lớn hơn đối với logic registry. Điều này cho phép các tính năng như xác thực, ủy quyền, quản lý phiên bản và cân bằng tải.
Công cụ Khám phá Dịch vụ (ví dụ: Consul, etcd, ZooKeeper): Các công cụ này được thiết kế để quản lý cấu hình dịch vụ và cung cấp khám phá dịch vụ động. Chúng có thể được sử dụng để lưu trữ và quản lý dữ liệu registry module federation.
Dịch vụ Cấu hình dựa trên Đám mây (ví dụ: AWS AppConfig, Azure App Configuration, Google Cloud Config): Các dịch vụ này cung cấp một cách tập trung và có thể mở rộng để quản lý cấu hình ứng dụng, bao gồm cả registry module federation.
Các Nền tảng Điều phối Microservice Hiện có (ví dụ: Kubernetes): Nếu bạn đã sử dụng một nền tảng điều phối microservice, bạn có thể tận dụng các tính năng quản lý cấu hình và khám phá dịch vụ tích hợp của nó cho registry module federation.

Ví dụ: Nền tảng Thương mại Điện tử Toàn cầu

Hãy tưởng tượng một nền tảng thương mại điện tử toàn cầu với các cửa hàng ở nhiều quốc gia. Mỗi quốc gia có thể có các danh mục sản phẩm, phương thức thanh toán và tùy chọn vận chuyển khác nhau. Registry Runtime có thể được sử dụng để tải động các module phù hợp dựa trên vị trí và sở thích của người dùng.

Ví dụ, người dùng ở Đức có thể thấy danh mục sản phẩm với mô tả tiếng Đức và giá bằng Euro, trong khi người dùng ở Nhật Bản có thể thấy danh mục sản phẩm với mô tả tiếng Nhật và giá bằng Yên. Registry Runtime sẽ xác định module nào cần tải dựa trên vị trí và sở thích của người dùng.

Hơn nữa, module thanh toán có thể được chọn động dựa trên vị trí của người dùng. Người dùng ở Đức có thể thấy các tùy chọn thanh toán bằng PayPal hoặc thẻ tín dụng, trong khi người dùng ở Nhật Bản có thể thấy các tùy chọn thanh toán bằng thẻ tín dụng hoặc thanh toán tại cửa hàng tiện lợi.

Mức độ tùy chỉnh động này rất khó đạt được nếu không có Registry Runtime.

Kết luận

Registry Runtime là một công cụ mạnh mẽ để cho phép khám phá module động trong JavaScript Module Federation. Nó mang lại nhiều lợi ích, bao gồm tách biệt, khả năng mở rộng, khả năng thích ứng và khả năng phục hồi. Mặc dù việc triển khai Registry Runtime làm tăng thêm độ phức tạp cho kiến trúc của bạn, nhưng lợi ích thường vượt trội hơn chi phí, đặc biệt đối với các ứng dụng lớn và phức tạp. Bằng cách xem xét cẩn thận các yếu tố được nêu trong bài viết này, bạn có thể triển khai thành công Registry Runtime và khai thác toàn bộ tiềm năng của Module Federation.

Khi kiến trúc microfrontend tiếp tục phát triển, Registry Runtime sẽ đóng vai trò ngày càng quan trọng trong việc cho phép các ứng dụng web có khả năng mở rộng và thích ứng. Hãy đón nhận công nghệ này và xây dựng tương lai của phát triển frontend.